In recent years, various kinds of communication systems, in particular mobile and/or IP-based (IP: Internet Protocol) communication systems, as well as a multitude of services offered in these systems have been developed.
In such advanced communication systems, such as e.g. Third Generation mobile communication networks currently under development by the Third Generation Partnership Program (3GPP) and the Third Generation Partnership Program 2 (3GPP2), aspects relating to security and trustworthiness are playing a more and more important role.
Starting from the concept of subscriber certificates, which support services that mobile operators provide and whose provision assists mobile operators, and in consideration of a need for more generic security capabilities, 3GPP and 3 GPP2 standardization work lately concentrated on the evolution of a generic authentication architecture (GAA). GAA defines bootstrapping of a shared (symmetric) secret based on specific credentials. As can be gathered from FIG. 1 showing an overview of a generic authentication architecture environment in interrelation with a home subscriber system HSS, a user equipment UE, and a network entity NE, GAA basically consists of three sub-aspects. That is, a generic bootstrapping architecture (GBA), subscriber certificates, and an authentication proxy (AP) e.g. based on HTTPS (Secure Hypertext Transport Protocol). Thereby, the generic bootstrapping architecture (GBA) also builds a basis for both the other sub-aspects in that GBA offers generic authentication capability for various applications based on an application specific shared secret or a public/private key pair. Usually, GBA functions to bootstrap authentication and key agreement for application security, and it is based on the AKA (Authentication and Key Agreement) mechanism.
In FIG. 2, there is illustrated a network model for generic bootstrapping. A bootstrapping server function BSF and the user equipment UE, which are connected via a bidirectional link, mutually authenticate using the AKA protocol, and agree on session keys. These keys are afterwards to be used for a bootstrapping session and to be used between the user equipment and a network application function NAF which is also connected to the user equipment by means of a bidirectional link. After a bootstrapping mechanism selection procedure and a bootstrapping procedure based on a selected bootstrapping mechanism, the user equipment and the network application function can run some application-specific protocol where the security of messages will be based on those session keys generated during mutual authentication. Accordingly, GAA/GBA can in general be regarded as a 3-party authentication scenario, wherein the bootstrapping server function is further connected to a home subscriber system (HSS) or Home Location Register (HLR).
The reference points (interfaces) between the individual entities in FIG. 2 are denoted by Ub, Ua, Zn, and Zh. The interface Zh is based on Diameter and may be based on MAP (not standard), the Zn interface can be based on Diameter or Web Services (i.e., SOAP over HTTP), the interface Ub is based on a reuse of HTTP Digest AKA messages (i.e., 3G authentication with USIM or ISIM) or some variant of it (e.g., 2G GBA of 3 GPP that is based on legacy GSM authentication, and legacy GBA in 3GPP2 that is based on CDMA 1x and CDMA 1x EvDo are all based on HTTP Digest AKA but with some modifications), and the protocol used on the interface Ua depends on the application to be executed.
The utilization of the generic bootstrapping architecture is divided into two phases, i.e. the (generic) bootstrapping procedure as such and the generic bootstrapping usage procedure. The present invention is concerned with the generic bootstrapping usage.
For further details on the generic bootstrapping architecture, reference is made to the document “3GPP TS 33.220, v7.3.0” as for 3GPP standardization and to the document “3GPP2 S.P0109-0, version 0.6” as for 3GPP2 standardization, both being published in December 2005.